Risk and liquidity management systems and methods

ABSTRACT

Example risk and liquidity management systems and methods are described. In one implementation, a financial management system identifies data associated with a plurality of events in a financial market in substantially real time. The financial management system analyzes the data associated with the plurality of events and, based on the analysis, determines a liquidity demand, a liquidity profile, and a risk profile associated with a particular financial institution. The financial management system then communicates the financial institution&#39;s liquidity demand, liquidity profile, and risk profile to the financial institution.

RELATED APPLICATIONS

This application is a Continuation In Part of U.S. patent applicationSer. No. 16/153,543, entitled “Data Ingestion Systems and Methods,”filed on Oct. 5, 2018, the disclosure of which is hereby incorporated byreference herein in its entirety. That application claims the prioritybenefit of U.S. Provisional Application Ser. No. 62/568,751, entitled“Data Ingestion Systems and Methods,” filed on Oct. 5, 2017, thedisclosure of which is hereby incorporated by reference herein in itsentirety.

This application also claims the priority benefit of U.S. ProvisionalApplication Ser. No. 62/607,783, entitled “Risk and Liquidity ManagementSystems and Methods,” filed on Dec. 19, 2017, the disclosure of which ishereby incorporated by reference herein in its entirety.

TECHNICAL FIELD

The present disclosure relates to financial systems and, moreparticularly, to systems and methods that manage financial risk andliquidity.

BACKGROUND

Various financial systems are used to transfer assets between differentorganizations, such as financial institutions. For example, in existingsystems, each financial institution maintains a ledger to keep track ofaccounts at the financial institution and transactions associated withthose accounts. Financial institutions generally cannot access theledger of another financial institution. Thus, a particular financialinstitution can only see part of a financial transaction (i.e., the partof the transaction associated with that financial institution'saccounts). When executing critical asset transfers, it is important thatall parties to the transfer can see the details of the transfer.Further, when tracking multiple trade events in multiple accounts everyday, it is important to efficiently handle the large amounts of datawhile managing financial risk and liquidity.

BRIEF DESCRIPTION OF THE DRAWINGS

Non-limiting and non-exhaustive embodiments of the present disclosureare described with reference to the following figures, wherein likereference numerals refer to like parts throughout the various figuresunless otherwise specified.

FIG. 1 is a block diagram illustrating an environment within which anexample embodiment may be implemented.

FIG. 2 is a block diagram illustrating an embodiment of a financialmanagement system configured to communicate with multiple other systems.

FIG. 3 illustrates an embodiment of an example asset transfer betweentwo financial institutions.

FIG. 4 illustrates an embodiment of a method for transferring assetsbetween two financial institutions.

FIG. 5 illustrates an embodiment of a method for authenticating a clientand validating a transaction.

FIG. 6 is a block diagram illustrating an embodiment of a financialmanagement system interacting with an API server and an audit server.

FIG. 7 illustrates an embodiment of an architecture for performing dataingestion as discussed herein.

FIG. 8 illustrates an embodiment of a process for performing dataingestion as discussed herein.

FIG. 9 illustrates an embodiment of a schema produced as a stream by amatcher.

FIG. 10 illustrates an embodiment of a logical sample of obligations andexposures.

FIG. 11 illustrates an embodiment of three orders received by anobligations/exposures processor.

FIG. 12 illustrates an embodiment of a second type of netting.

FIG. 13 illustrates an embodiment of a third type of netting.

FIG. 14 illustrates an embodiment of a fourth type of netting.

FIG. 15 illustrates an embodiment of a fifth type of netting.

FIG. 16 illustrates an embodiment of a signal that is sent when thesettlement happens for a netted entry.

FIG. 17 illustrates an embodiment of another signal that is sent whenthe settlement happens for a netted entry.

FIG. 18 illustrates an embodiment of a data flow diagram as a sampleapplication.

FIG. 19 illustrates an embodiment of a method for managing a financialinstitution's risk and liquidity.

FIG. 20 illustrates an example state diagram showing various states thata transaction may pass through.

FIG. 21 is a block diagram illustrating an embodiment of a financialmanagement system interacting with a cryptographic service and multipleclient nodes.

FIG. 22 is a block diagram illustrating an example computing device.

DETAILED DESCRIPTION

It will be readily understood that the components of the present systemsand methods, as generally described and illustrated in the figuresherein, could be arranged and designed in a wide variety of differentconfigurations. The following detailed description of the embodiments ofthe data ingestion systems and methods is not intended to limit thescope of the invention, as claimed, but is merely representative ofcertain examples of presently contemplated embodiments in accordancewith the invention.

Existing financial institutions typically maintain account informationand asset transfer details in a ledger at the financial institution. Theledgers at different financial institutions do not communicate with oneanother and often use different data storage formats or protocols. Thus,each financial institution can only access its own ledger and cannot seedata in another financial institution's ledger, even if the twofinancial institutions implemented a common asset transfer.

The systems and methods described herein enable institutions to moveassets on demand by enabling authorized users to execute complexworkflows. Additionally, the described systems and methods allow one ormore 3rd parties to view and confirm payment activities betweenparticipants. Further, the systems and methods support thesynchronization of data, such as transaction data, across multipleledgers. In some embodiments, the multiple ledgers are heterogeneousledgers. In other situations, the multiple ledgers are non-heterogeneousledgers. The systems and methods described herein are capable ofon-demand settlements across multiple ledgers. Additionally, the systemsand methods discussed herein are operable with DLT (Distributed LedgerTechnology) systems and non-DLT systems. In some examples discussedherein, the systems and methods are discussed with respect to one ormore financial institutions. However, the described systems and methodsare applicable to any type of system associated with any entity. Thedescribed systems and methods are not limited to use with financialinstitutions.

As discussed herein, distributed ledger technology (DLT) is a databaseor other data storage mechanism that is spread across multiple systemsor sites, such as different institutions and/or different geographicareas.

As used herein, a workflow describes, for example, the sequence ofactivities associated with a particular transaction, such as an assettransfer. In particular, the systems and methods provide a clearing andsettlement gateway between, for example, multiple financialinstitutions. When a workflow is executed, the system generates andissues clearing and settlement messages (or instructions) to facilitatethe movement of assets. A shared permissioned ledger (discussed herein)keeps track of the asset movement and provides visibility to theprincipals and observers in substantially real time. The integrity ofthese systems and methods is important because the systems are dealingwith core payments that are a critical part of banking operations.Additionally, many asset movements are final and irreversible.Therefore, the authenticity of the request and the accuracy of theinstructions are crucial. Further, reconciliation of transactionsbetween multiple parties are important to the management of financialdata.

As discussed herein, payments between parties can be performed usingmultiple asset types, including currencies, treasuries, securities(e.g., notes, bonds, bills, and equities), and the like. Payments can bemade for different reasons, such as margin movements, collateralpledging, swaps, delivery, fees, liquidation proceeds, and the like. Asdiscussed herein, each payment may be associated with one or moremetadata.

As used herein, DCC refers to a direct clearing client or an individualor institution that owes an obligation. A payee refers to an individualor institution that is owed an obligation. A CCG (or Guarantor) refersto a client clearing guarantor or an institution that guarantees thepayment of an obligation. A CCP refers to a central counterpartyclearinghouse and a Client is a customer of the FCM (Futures ClearingMerchant)/CCG guarantor. Collateral settlements refer to non-cash basedassets that are cleared and settled between CCP, FCM/CCG guarantor, andDCC. CSW refers to collateral substitution workflow, which is a workflowused for the pledging and recall (including substitution) of collateralfor cash. A clearing group refers to a logical grouping of stakeholderswho are members of that clearing group that are involved in the clearingand settlement of one or more asset types. A workflow, when executed,facilitates a sequence of clearing and settlement instructions betweenmembers of a clearing group as specified by the workflow parameters.

When some financial transactions change state (e.g.,initiated—pending—approved—cleared—settled, etc.) it may trigger one ormore notifications to the principals involved in the transaction. Thesystems and methods described herein provide multiple ways to receiveand respond to these notifications. In some embodiments, thesenotifications can be viewed and acknowledged using a dashboardassociated with the described systems and methods or using one or moreAPIs.

As used herein, principals refer to the parties that are directlyinvolved in a payment or transaction origination or termination. Anobserver refers to a party that is not a principal, but may be astakeholder in a transaction. In some embodiments, an observer cansubscribe for a subset of notifications generated by the systems andmethods discussed herein. In some situations, one or more principals mayneed to agree that the observer can receive the subset of notifications.APIs refer to an application program interface that allow other systemsand devices to integrate with the systems and methods described herein.

The systems and methods described herein provide a payment platform thatenables the movement of assets between principals. The platform alsoprovides real time visibility into the funds flow with the use of ashared ledger (e.g., a shared, permissioned, and replicated ledger).Using the shared ledger, users can generate reports on the assetmovements and status of the workflows.

In capital markets, the asset movement is triggered due to a settlementon a set of trades between principals. All parties involved in the tradeas well as the clearing and settlement of the trade need to perform posttrade activities that include reconciliation and regulatory reporting ofthe trades as well as the payments associated with the trades.Reconciliation and regulatory reporting is a significant pain point foroperations teams since it is mostly manual and labor intensive. The mainproblems related to reconciliation and the regulatory reporting are theheterogeneous systems that are involved in the trade data and thepayments. The systems and methods described herein provide a platform tomove the assets as part of settlement. These systems and methods canextend this to capture the trade-level information that resulted in theasset movement (settlement). When this functionality is extended toparticipants on the platform, the reconciliation efforts can beminimized as participants can use the shared and permissioned featuresof the shared ledger to generate the reconciliation and regulatoryreports.

The number of trade events that happen in a day is 3 to 5 orders ofmagnitude higher than the number of settlements that happen in a day.The data ingestion platform should be able to capture all of the tradeevents. By extending a data ingestion engine and integrating it with thepayments, the systems and methods described herein are able to tie thesettlements to the trades. This simplifies the reconciliation andregulatory reporting problems experienced by institutions, users, andthe like.

FIG. 1 is a block diagram illustrating an environment 100 within whichan example embodiment may be implemented. A financial management system102 is coupled to a data communication network 104 and communicates withone or more other systems, such as financial institutions 106, 108, anauthorized system 110, an authorized user device 112, and a replicateddata store 114. As discussed in greater detail herein, financialmanagement system 102 performs a variety of operations, such asfacilitating the transfer of assets between multiple financialinstitutions or other entities, systems, or devices. Although many assettransfers include the use of a central bank to clear and settle thefunds, the central bank is not shown in FIG. 1. A central bank providesfinancial services for a country's government and commercial bankingsystem. In the United States, the central bank is the Federal ReserveBank. In some implementations, financial management system 102 providesan on-demand gateway integrated into the heterogeneous core ledgers offinancial institutions (e.g., banks) to view funds and clear and settleall asset classes. Additionally, financial management system 102 mayefficiently settle funds using existing services such as FedWire.

In some embodiments, data communication network 104 includes any type ofnetwork, such as a local area network, a wide area network, theInternet, a cellular communication network, or any combination of two ormore communication networks. The described systems and methods can useany communication protocol supported by a financial institution's ledgerand other systems. For example, the communication protocol may includeSWIFT MT (Society for Worldwide Interbank Financial TelecommunicationMessage Type) messages (such as MT 2XX, 5XX, 9XX), ISO 20022 (a standardfor electronic data interchange between financial institutions), andproprietary application interfaces exposed by particular financialinstitutions. Financial institutions 106, 108 include banks, exchanges,hedge funds, and any other type of financial entity or system. In someembodiments, financial management system 102 interacts with financialinstitutions 106, 108 using existing APIs and other protocols alreadybeing used by financial institutions 106, 108, thereby allowingfinancial management system 102 to interact with existing financialinstitutions without significant modification to the financialinstitution's systems. Authorized system 110 and authorized user device112 include any type of system, device, or component that is authorizedto communicate with financial management system 102. Replicated datastore 114 stores any type of data accessible by any number of systemsand devices, such as the systems and devices described herein. In someembodiments, replicated data store 114 stores immutable and auditableforms of transaction data between financial institutions. The immutabledata cannot be deleted or modified. In particular implementations,replicated data store 114 is an append only data store which keeps trackof all intermediate states of the transactions. Additional metadata maybe stored along with the transaction data for referencing informationavailable in external systems. In specific embodiments, replicated datastore 114 may be contained within a financial institution or othersystem.

As shown in FIG. 1, financial management system 102 is also coupled to adata store 116 and a ledger 118. In some embodiments, data store 116 isconfigured to store data used during the operation of financialmanagement system 102. Ledger 118 stores data associated with multiplefinancial transactions, such as asset transfers between two financialinstitutions. As discussed herein, ledger 118 is constructed in a mannerthat tracks when a transaction was initiated and who initiated thetransaction. Thus, ledger 118 can track all transactions and generate anaudit trail, as discussed herein. Using an audit server of the typedescribed with respect to FIG. 6, financial management system 102 cansupport audit trails from both the financial management system andexternal systems and devices. In some embodiments, each transactionentry in ledger 118 records a client identifier, a hash of thetransaction, an initiator of the transaction, and a time of thetransaction. This data is useful in auditing the transaction data.

In some embodiments, ledger 118 is modeled after double-entry accountingsystems where each transaction has two entries (i.e., one entry for eachof the principals to the transaction). The entries in ledger 118 includedata related to the principal parties to the transaction, a transactiondate, a transaction amount, a transaction state, any relevant workflowreference, a transaction ID, and any additional metadata to associatethe transactions with one or more external systems. The entries inledger 118 also include cryptographic hashes to provide tamperresistance and auditability. Users for each of the principals to thetransaction only have access to their own entries (i.e., thetransactions to which the principal was a party). Access to the entriesin ledger 118 can be further restricted or controlled based on a user'srole or a party's role, where certain data is only available to certainroles.

In some embodiments, ledger 118 is a shared ledger that can be accessedby multiple financial institutions and other systems and devices. Inparticular implementations, both parties to a specific transaction canaccess all details related to that transaction stored in ledger 118. Alldetails related to the transaction include, for example, the partiesinvolved in the transaction, the type of transaction, the date and timeof the transaction, the amount of the transaction, and other dataassociated with the transaction. Additionally, ledger 118 restrictspermission to access specific transaction details based on relevanttrades associated with a particular party. For example, if a specificparty (such as a financial institution or other entity) requests accessto data in ledger 118, that party can only access (or view) dataassociated with transactions to which the party was involved. Thus, aspecific party cannot see data associated with transactions that areassociated with other parties and do not include the specific party.

The shared permission aspects of ledger 118 provides for a subset of theledger data to be replicated at various client nodes and other systems.The financial management systems and methods discussed herein allowselective replication of data. Thus, principals, financial institutions,and other entities do not have to hold data for transactions to whichthey were not a party.

It will be appreciated that the embodiment of FIG. 1 is given by way ofexample only. Other embodiments may include fewer or additionalcomponents without departing from the scope of the disclosure.Additionally, illustrated components may be combined or included withinother components without limitation. In some embodiments, financialmanagement system 102 may also be referred to as a “financial managementplatform,” “financial transaction system,” “financial transactionplatform,” “asset management system,” or “asset management platform.”

In some embodiments, financial management system 102 interacts withauthorized systems and authorized users. The authorized set of systemsand users often reside outside the jurisdiction of financial managementsystem 102. Typically, interactions with these systems and users areperformed via secured channels. To ensure the integrity of financialmanagement system 102, various constructs are used to providesystem/platform integrity as well as data integrity.

In some embodiments, system/platform integrity is provided by usingauthorized (e.g., whitelisted) machines and devices, and verifying theidentity of each machine using security certificates, cryptographickeys, and the like. In certain implementations, particular API accesspoints are determined to ensure that a specific communication originatesfrom a known enterprise or system. Additionally, the systems and methodsdescribed herein maintain a set of authorized users and roles, which mayinclude actual users, systems, devices, or applications that areauthorized to interact with financial management system 102.System/platform integrity is also provided through the use of securechannels to communicate between financial management system 102 andexternal systems. In some embodiments, communication between financialmanagement system 102 and external systems is performed using highlysecure TLS (Transport Layer Security) with well-established handshakesbetween financial management system 102 and the external systems.Particular implementations may use dedicated virtual private clouds(VPCs) for communication between financial management system 102 and anyexternal systems. Dedicated VPCs offer clients the ability to set uptheir own security and rules for accessing financial management system102. In some situations, an external system or user may use theDirectConnect network service for better service-level agreements andsecurity.

In some embodiments financial management system 102 allows each clientto configure and leverage their own authentication systems. This allowsclients to set their custom policies on user identity verification(including 2FA (two factor authentication)) and account verification. Anauthentication layer in file management system 102 delegates requests toclient systems and allows the financial management system to communicatewith multiple client authentication mechanisms.

Financial management system 102 also supports role-based access controlof workflows and the actions associated with workflows. Exampleworkflows may include Payment vs Payment (PVP) and Delivery vs Payment(DVP) workflows. In some embodiments, users can customize a workflow toadd their own custom steps to integrate with external systems that cantrigger a change in transaction state or associate them with manualsteps. Additionally, system developers can develop custom workflows tosupport new business processes. In particular implementations, some ofthe actions performed by a workflow can be manual approvals, a SWIFTmessage request/response, scheduled or time-based actions, and the like.In some embodiments, roles can be assigned to particular users andaccess control lists can be applied to roles. An access control listcontrols access to actions and operations on entities within a network.This approach provides a hierarchical way of assigning privileges tousers. A set of roles also includes roles related to replication ofdata, which allows financial management system 102 to identify what datacan be replicated and who is the authorized user to be receiving thedata at an external system.

In some embodiments, financial management system 102 detects and recordsall client metadata, which creates an audit trail for the clientmetadata. Additionally, one or more rules identify anomalies which maytrigger a manual intervention by a user or principal to resolve theissue. Example anomalies include system request patterns that are notexpected, such as a high number of failed login attempts, passwordresets, invalid certificates, volume of requests, excessive timeouts,http errors, and the like. Anomalies may also include data requestpatterns that are not expected, such as first time use of an accountnumber, significantly larger than normal amount of payments beingrequested, attempts to move funds from an account just added, and thelike. When an anomaly is triggered, financial management system 102 iscapable of taking a set of actions. The set of actions may initially belimited to pausing the action, notifying the principals of the anomaly,and only resuming activity upon approval from a principal.

FIG. 2 is a block diagram illustrating an embodiment of financialmanagement system 102 configured to communicate with multiple othersystems. As shown in FIG. 2, financial management system 102 may beconfigured to communicate with one or more CCPs (Central CounterpartClearing Houses) 220, one or more exchanges 222, one or more banks 224,one or more asset managers 226, one or more hedge funds 228, and one ormore fast data ingestion systems (or “pipes”) 230. CCPs 220 areorganizations that facilitate trading in various financial markets.Exchanges 222 are marketplaces in which securities, commodities,derivatives, and other financial instruments are traded. Banks 224include any type of bank, credit union, savings and loan, or otherfinancial institution. Asset managers 226 include asset managementorganizations, asset management systems, and the like. In addition tohedge funds 228, financial management system 102 may also be configuredto communicate with other types of funds, such as mutual funds.Financial management system 102 may communicate with CCPs 220, exchanges222, banks 224, asset managers 226, and hedge funds 228 using any typeof communication network and any communication protocol. Fast dataingestion systems 230 include at least one data ingestion platform thatconsumes trades in real-time along with associated events and relatedmetadata. The platform is a high throughput pipe which provides anability to ingest trade data in multiple formats. The trade data arenormalized to a canonical format, which is used by downstream engineslike matching, netting, real-time counts, and liquidity projections andoptimizers. The platform also provides access to information inreal-time to different parties of the trade. In some embodiments fastdata ingestion systems 230 may include one or more data ingestionengines. Additional details regarding the data ingestion engines and thedata ingestion process are provided herein.

Financial management system 102 includes secure APIs 202 that are usedby partners to securely communicate with financial management system102. In some embodiments, the APIs are stateless to allow for automaticscaling and load balancing. Role-based access controller 204 provideaccess to modules, data and activities based on the roles of anindividual user or participant interacting with financial managementsystem 102. In some embodiments, users belong to roles that are givenpermissions to perform certain actions. An API request may be checkedagainst the role to determine whether the user has proper permissions toperform an action. An onboarding module 206 includes all of the metadataassociated with a particular financial institution, such as bank accountinformation, user information, roles, permissions, clearing groups,assets, and supported workflows. A clearing module 208 includes, forexample, a service that provides the functionality to transfer assetsbetween accounts within a financial institution. A settlement module 210monitors and manages the settlement of funds or other types of assetsassociated with one or more transactions handled by financial managementsystem 102.

Financial management system 102 also includes a ledger manager 212 thatmanages a ledger (e.g., ledger 118 in FIG. 1) as discussed herein. AFedWire, NSS (National Settlement Service), ACH (Automated ClearingHouse), Interchange module 214 provides a service used to interact withstandard protocols like FedWire and ACH for the settlement of funds. Ablockchain module 216 provides interoperability with blockchains forsettlement of assets on a blockchain. A database ledger and replicationmodule 218 provides a service that exposes constructs of a ledger to thefinancial management system. Database ledger and replication module 218provides functionality to store immutable transaction states with theability to audit them. The transaction data can also be replicated toauthorized nodes for which they are either a principal or an observer.Although particular components are shown in FIG. 2, alternateembodiments of financial management system 102 may contain additionalcomponents not shown in FIG. 2, or may not contain some components shownin FIG. 2. Although not illustrated in FIG. 2, financial managementsystem 102 may contain one or more processors, one or more memorydevices, and other components such as those discussed herein withrespect to FIG. 14.

In the example of FIG. 2, various modules, components, and systems areshown as being part of financial management system 102. For example,financial management system 102 may be implemented, at least in part, asa cloud-based system. In other examples, financial management system 102is implemented, at least on part, in one or more data centers. In someembodiments, some of these modules, components, and systems may bestored in (and/or executed by) multiple different systems. For example,certain modules, components, and systems may be stored in (and/orexecuted by) one or more financial institutions.

As mentioned above, system/platform integrity is important to the secureoperation of financial management system 102. This integrity ismaintained by ensuring that all actions are initiated by authorizedusers or systems. Additionally, once an action is initiated and theassociated data is created, an audit trail of any changes made, andother information related to the action is recorded for futurereference.

In particular embodiments, financial management system 102 includes (orinteracts with) a roles database and an authentication layer. The rolesdatabase stores various roles of the type discussed herein.

FIG. 3 illustrates an embodiment 300 of an example asset transferbetween two financial institutions. In the example of FIG. 3, financialmanagement system 302 is in communication with a first bank 304 and asecond bank 306. In this example, funds are being transferred from anaccount at bank 304 to an account at bank 306, as indicated by brokenline 308. Bank 304 maintains a ledger 310 that identifies alltransactions and data associated with transactions that involve bank304. Similarly, bank 306 maintains a ledger 318 that identifies alltransactions and data associated with transactions that involve bank306. In some embodiments, ledgers 310 and 318 (or the data associatedwith ledgers 310 and 318) reside in financial management system 302 as ashared, permissioned ledger, such as ledger 118 discussed above withrespect to FIG. 1.

In the example of FIG. 3, funds are being transferred out of an account312 at bank 304. To facilitate the transfer of funds out of account 312,the funds being transferred are moved 316 from account 312 to a firstsuspense account 314 at bank 304. Each suspense account discussed hereinis a “For Benefit Of” (FBO) account and is operated by the financialmanagement system for the members of the network (i.e., all parties andprincipals). The financial management system may facilitate the transferof assets into and out of the suspense accounts. However, the financialmanagement system does not take ownership of the assets in the suspenseaccounts. The credits and debits associated with each suspense accountare issued by the financial management system and the ledger (e.g.,ledger 118 in FIG. 1) is used to track ownership of the funds in thesuspense accounts. Each suspense account has associated governance rulesthat define how the suspense account operates. At bank 306, thetransferred funds are received by a second suspense account 322. Thefunds are moved 324 from second suspense account 322 to an account 320at bank 306. In some embodiments, a suspense account may be referred toas a settlement account.

As discussed herein, financial management system 302 facilitates thetransfer of funds between bank 304 and 306. Additional details regardingthe manner in which the funds are transferred are provided below withrespect to FIG. 4. Although only one account and one suspense account isshown for each bank in FIG. 3, particular embodiments of bank 304 and306 may contain any number of accounts and suspense accounts.Additionally, bank 304 and 306 may contain any number of ledgers andother systems. In some embodiments, each suspense account 314, 322 isestablished as part of the financial institution “onboarding” processwith the financial management system. For example, the financialmanagement system administrators may work with financial institutions toestablish suspense accounts that can interact with the financialmanagement system as described herein.

In some embodiments, one or more components discussed herein arecontained in a traditional infrastructure of a bank or other financialinstitution. For example, an HSM (Hardware Security Module) in a bankmay execute software or contain hardware components that interact with afinancial management system to facilitate the various methods andsystems discussed herein. In some embodiments, the HSM provides securitysignatures and other authentication mechanisms to authenticateparticipants of a transaction.

FIG. 4 illustrates an embodiment of a method 400 for transferring assets(e.g., funds) between two financial institutions. Initially, a financialmanagement system receives 402 a request to transfer funds from anaccount at Bank A to an account at Bank B. The request may be receivedby Bank A, Bank B, or another financial institution, system, device, andthe like. Using the example of FIG. 3, financial management system 302receives a request to transfer funds from account 312 at bank 304 toaccount 320 at bank 306.

Method 400 continues as the financial management system confirms 404available funds for the transfer. For example, financial managementsystem 302 in FIG. 3 may confirm that account 312 at bank 304 containssufficient funds to satisfy the amount of funds defined in the receivedtransfer request. In some embodiments, if available funds are confirmedat 404, the financial management system creates suspense account A atBank A and creates suspense account B at Bank B. In particularimplementations, suspense account A and suspense account B are temporarysuspense accounts created for a particular transfer of funds. In otherimplementations, suspense account A and suspense account B are temporarysuspense accounts but are used for a period of time (or for a number oftransactions) to support transfers between bank A and bank B.

If available funds are confirmed at 404, then account A101 at Bank A isdebited 406 by the transfer amount and suspense account A (at Bank A) iscredited with the transfer amount. Using the example of FIG. 3,financial management system 302 debits the transfer amount from account312 and credits that transfer amount to suspense account 314. In someembodiments, ownership of the transferred assets changes as soon as thetransfer amount is credited to suspense account 314.

The transferred funds are then settled 408 from suspense account A (atBank A) to suspense account B (at Bank B). For example, financialmanagement system 302 in FIG. 3 may settle funds from suspense account314 in bank 304 to suspense account 322 in bank 306. The settlement offunds between two suspense accounts is determined by the counterpartyrules set up between the two financial institutions involved in thetransfer of funds. For example, a counterparty may choose to settle atthe top of the hour or at a certain threshold to manage risk exposure.The settlement process may be determined by the asset type, thefinancial institution pair, and/or the type of transaction. In someembodiments, transactions can be configured to settle in gross or net.For gross transaction settlement of a PVP workflow, the settlementoccurs instantaneously over existing protocols supported by financialinstitutions, such as FedWire, NSS, and the like. Netted transactionsmay also settle over existing protocols based on counterparty andnetting rules. In some embodiments, the funds are settled after eachfunds transfer. In other embodiments, the funds are settledperiodically, such as once an hour or once a day. Thus, rather thansettling the two suspense accounts after each funds transfer between twofinancial institutions, the suspense accounts are settled after multipletransfers that occur over a period of time. Alternatively, someembodiments settle the two suspense accounts when the amount due to onefinancial institution exceeds a threshold value.

Method 400 continues as suspense account B (at Bank B) is debited 410 bythe transfer amount and account B101 at Bank B is credited with thetransfer amount. For example, financial management system 302 in FIG. 3may debit suspense account 322 and credit account 320. After finishingstep 410, the funds transfer from account 312 at bank 304 to account 320at bank 306 is complete.

In some embodiments, the financial management system facilitates (orinitiates) the debit, credit, and settlement activities (as discussedwith respect to FIG. 4) by sending appropriate instructions to Bank Aand/or Bank B. The appropriate bank then performs the instructions toimplement at least a portion of method 400. The example of method 400can be performed with any type of asset. In some embodiments, the assettransfer is a transfer of funds using one or more traditionalcurrencies, such as U.S. Dollars (USD) or Great British Pounds (GBP).

FIG. 5 illustrates an embodiment of a method 500 for authenticating aclient and validating a transaction. Initially, a financial managementsystem receives 502 a connection request from a client node, such as afinancial institution, an authorized system, an authorized user device,or other client types mentioned herein. The financial management systemauthenticates 504 and, if authenticated, acknowledges the client node asknown. Method 500 continues as the financial management system receives506 a login request from the client node. In response to the loginrequest, the financial management system generates 508 an authenticationtoken and communicates the authentication token to the client node. Insome embodiments, the authentication token is used to determine theidentity of the user for future requests, such as fund transferrequests. The identity is then further checked for permissions to thevarious services or actions.

The financial management system further receives 510 a transactionrequest from the client node, such as a request to transfer assetsbetween two financial institutions or other entities. In response to thereceived transaction request, the financial management system verifies512 the client node's identity and validates the requested transaction.In some embodiments, the client node's identity is validated based on anauthentication token, and then permissions are checked to determine ifthe user has permissions to perform a particular action or transaction.Transfers of assets also involve validating approval of an account bymultiple roles to avoid compromising the network. If the client node'sidentity and requested transaction are verified, the financialmanagement system creates 514 one or more ledger entries to store thedetails of the transaction. The ledger entries may be stored in a ledgersuch as ledger 118 discussed herein. The financial management systemthen sends 516 an acknowledgement regarding the transaction to theclient node with a server transaction token. In some embodiments, theserver transaction token is used at a future time by the client whenconducting audits. Finally, the financial management system initiates518 the transaction using, for example, the systems and methodsdiscussed herein.

In some embodiments, various constructs are used to ensure dataintegrity. For example, cryptographic safeguards allow a transaction tospan 1-n principals. The financial management system ensures that noother users (other than the principals who are parties to thetransaction) can view data in transit. Additionally, no other usershould have visibility into the data as it traverses the variouschannels. In some embodiments, there is a confirmation that atransaction was received completely and correctly. The financialmanagement system also handles failure scenarios, such as loss ofconnectivity in the middle of the transaction. Any data transmitted to asystem or device should be explicitly authorized such that each entry(e.g., ledger entry) can only be seen and read by the principals whowere a party to the transaction. Additionally, principals can givepermission to regulators and other individuals to view the dataselectively.

Cryptographic safeguards are used to detect data tampering in thefinancial management system and any other systems or devices. Datawritten to the ledger and any replicated data may be protected by:

-   -   Stapling all the events associated with a single transaction.    -   Providing logical connections of each commit to those that came        before it are made.    -   The logical connections are also immutable, but principals can        send messages for relinking. In this case, the current and all        preceding links are maintained. For example, trade amendments        are quite common. A trade amendment needs to be connected to the        original trade. For forensic analysis, a bank may wish to        identify all trades by a particular trader. Query        characteristics will be graphs, time series, and RDBMS        (Relational Database Management System).

In some embodiments, the financial management system monitors for datatampering. If the data store (central data store or replicated datastore) is compromised in any way and the data is altered, the financialmanagement system should be able to detect exactly what changed.Specifically, the financial management system should guarantee allparticipants on the network that their data has not been compromised orchanged. Information associated with changes are made available viaevents such that the events can be sent to principals via messaging oravailable to view on, for example, a user interface. Regarding dataforensics, the financial management system is able to determine that theprevious value of an attribute was X, it is now Y and it was changed attime T, by a person A. If a system is hacked or compromised, there maybe any number of changes to attribute X and all of those changes arecaptured by the financial management system, which makes the tamperingevident.

In particular embodiments, the financial management system leverages thebest security practices for SaaS (Software as a Service) platforms toprovide cryptographic safeguards for ensuring integrity of the data. Forensuring data integrity, the handshake between the client and an APIserver (discussed with respect to FIG. 6) establish a mechanism whichallows both the client and the server to verify the authenticity oftransactions independently. Additionally, the handshake provides amechanism for both the client and the server to agree on a state of theledger. If a disagreement occurs, the ledger can be queried to determinethe source of the conflict.

FIG. 6 is a block diagram illustrating an embodiment 600 of a financialmanagement system 602 interacting with an API server 608 and an auditserver 610. Financial management system 602 also interacts with a datastore 604 and a ledger 606. In some embodiments, data store 604 andledger 606 are similar to data store 116 and ledger 118 discussed hereinwith respect to FIG. 1. In particular implementations, API server 608exposes functionality of financial management system 602, such as APIsthat provide reports of transactions and APIs that allow foradministration of nodes and counterparties. Audit server 610periodically polls the ledger to check for data tampering of ledgerentries. This check of the ledger is based on, for example,cryptographic hashes and are used to monitor data tampering as describedherein.

In some embodiments, all interactions with financial management system602 or the API server are secured with TLS. API server 608 and auditserver 610 may communicate with financial management system 602 usingany type of data communication link or data communication network, suchas a local area network or the Internet. Although API server 608 andaudit server 610 are shown in FIG. 6 as separate components, in someembodiments, API server 608 and/or audit server 610 may be incorporatedinto financial management system 602. In particular implementations, asingle server may perform the functions of API server 608 and auditserver 610.

In some embodiments, at startup, a client sends a few checksums it hassent and transaction IDs to API server 608, which can verify thechecksums and transaction IDs, and take additional traffic from theclient upon verification. In the case of a new client, mutually agreedupon seed data is used at startup. A client request may be accompaniedby a client signature and, in some cases, a previous signature sent bythe server. The server verifies the client request and the previousserver signature to acknowledge the client request. The client persiststhe last server signature and a random set of server hashes forauditing. Both client and server signatures are saved with requests tohelp quickly audit correctness of the financial management systemledger. The block size of transactions contained in the request may bedetermined by the client. A client SDK (Software Development Kit)assists with the client server handshake and embedding on server sidesignatures. The SDK also persists a configurable amount of serversignatures to help with restart and for random audits. Clients can alsoset appropriate block size for requests depending on their transactionrates. The embedding of previous server signatures in the current clientblock provides a way to chain requests and provide an easy mechanism todetect tampering. In addition to a client-side signature, the requestsare encrypted using standard public key cryptography to provideadditional defense against client impersonation. API server 608 logs allencrypted requests from the client. The encrypted requests are used, forexample, during data forensics to resolve any disputes.

In particular implementations, a client may communicate a combination ofa previous checksum, a current transaction, and a hash of the currenttransaction to the financial management system. Upon receipt of theinformation, the financial management system checks the previouschecksum and computes a new checksum, and stores the client hash, thecurrent transaction, and the current checksum in a storage device, suchas data store 604. The checksum history and hash (discussed herein)protect the integrity of the data. Any modification to an existing rowin the ledger cannot be made easily because it would be detected bymismatched checksums in the historical data, thereby making it difficultto alter the data.

The integrity of financial management system 602 is ensured by havingserver audits at regular intervals. Since financial management system602 uses chained signatures per client at the financial managementsystem, it ensures that an administrator of financial management system602 cannot delete or update any entries without making the ledger tamperevident. In some embodiments, the auditing is done at two levels: aminimal level which the SDK enforces using a randomly selected set ofserver signatures to perform an audit check; and a more thorough auditcheck run at less frequent intervals to ensure that the data is correct.

In some implementations, financial management system 602 allows for theselective replication of data. This approach allows principals or banksto only hold data for transactions they were a party to, while avoidingstorage of other data related to transactions in which they were notinvolved. Additionally, financial management system 602 does not requireclients to maintain a copy of the data associated with theirtransactions. Clients can request the data to be replicated to them atany time. Clients can verify the authenticity of the data by using thereplicated data and comparing the signature the client sent to thefinancial management system with the request.

In some embodiments, a notarial system is used to maintain auditabilityand forensics for the core systems. Rather than relying on a singlenotary hosted by the financial management system, particular embodimentsallow the notarial system to be installed and executed on any systemthat interacts with the financial management system (e.g., financialinstitutions or clients that facilitate transactions initiated by thefinancial management system).

The systems and methods discussed herein support different assetclasses. Each asset class may have a supporting set of metadatacharacteristics that are distinct. Additionally, the requests and datamay be communicated through multiple “hops” between the originatingsystem and the financial management system. During these hops, data maybe augmented (e.g., adding trade positions, account details, and thelike) or changed.

In certain types of transactions, such as cash transactions, thefinancial management system streamlines the workflow by supporting richmetadata accompanying each cash transfer. This rich metadata helps bankstie back cash movements to trades, accounts, and clients.

As discussed herein, the described systems and methods facilitate themovement of assets between principals (also referred to as“participants”). The participants are typically large financialinstitutions in capital markets that trade multiple financial products.Trades in capital markets can be complex and involve large assetmovements (also referred to as “settlements”). The systems and methodsdescribed herein can integrate to financial institutions and centralsettlement authorities such as the US Federal Reserve or DTCC(Depository Trust & Clearing Corporation) to facilitate the finalsettlement of assets. The described systems and methods also have theability to execute workflows such as DVP, threshold based settlement, ortime-based settlement between participants. Using the workflows,transactions are settled in gross or net amounts.

The systems and methods described herein include a platform and workflowto support and enable 3rd party guarantors the ability to view paymentactivity between participants in real time (or substantially real time),and step in to make payments on behalf of participants when necessary.

The ACH (Automated Clearing House) payment service enables companies toelectronically collect payments from customers for either one-off orrecurring payments by directly debiting a customer's checking or savingaccounts. Common uses of ACH include online bill payment, mortgage andloan repayment, and direct deposit of payroll. Also, many investmentmanagers and brokerage firms allow users to link a bank account or anonline funding source to a trading account.

Traditionally, connecting directly to bank accounts has been preferredfor the following reasons:

1. Lower cost to transfer money using ACH versus paper checks or creditcards

2. Ability to move large amounts of money

3. Fewer instances of fraud from bank accounts compared to credit cards

As used herein, a retail payment is considered a movement of amountssmaller than $100,000 (although this can be any amount). Typically,retail payments in and out of a bank account are settled over settlementvenues and protocols such as ACH in the U.S., SEPA (Single Euro PaymentsArea), NACH in India, etc. These payments have the following advantages:

Low Costs

Ability to schedule automatic payments

Ability to issue a debit pull or credit push

Despite the advantages mentioned above, ACH has the followingdisadvantages:

Inability to determine the validity of the account (this is possible ifthe user has closed the bank account at a later point in time)

Inability to determine the balance in the account even if valid (arethere sufficient funds to cover the transaction?)

Slow multi-phased settlement protocol that can take hours or even days

Various Reject codes and ability to recall the payments later by theaccount holder

In some situations, rejections in payments are in the range of 1-10%depending on the type of products that are being purchased. For example,certain types of product purchases (e.g., electronics, jewelry, and thelike) are more prone to fraud.

Adding a funding source and moving money

In some situations, online sites and other vendors perform the followingsteps when linking a bank account.

1. Select a bank from a list of popular retail banks using either of thefollowing:

A. IAV (Instant Account Verification) process. This is done by askingthe user to submit the username and password for the bank (or account).The website or process then proceeds to use these credentials to log inon behalf of the user to validate the account. Since the bankcredentials are being required by the site, many users are comfortablesharing this information with well reputed companies or financialinstitutions.

B. Micro Deposits: The website or process follows a multi-step procedureas follows:

i. The user enters the account number and routing number of theirbanking institution.

ii. The website or process then makes two or more deposits of smallamounts, typically less than $0.25, using the account number and routingnumber.

iii. If the above step fails, the account number and routing number areconsidered to be incorrect and the user has to return to the beginningof the process to add a funding source. If there is no error, theprocess proceeds to the next step.

iv. The user comes back to the website or process to complete theaddition of the bank account as the funding source by validating the twomicro deposit amounts. The fact that the user knew their account numberand the routing number, and then was able to accurately validate the twomicro deposits is enough proof that the user is indeed the owner of theaccount. In addition, it also satisfies the BSA (Bank Secrecy Act)requirement for the website or process.

2. Once the bank account has been added as a funding source, the websiteor process will attempt to debit money from or credit money to theaccount. Debits are done when the website or process attempts to “pull”money from the account to complete a transaction. Credits are done whenthe website or process allows the user to “push” money to their bankaccount. This is done when the website or process has an associatedproduct that allows the user to hold money in their account. This can befor online payments products, brokerage accounts, tax products, auctionsites, mortgage or rent payments, and the like.

3. Payments in and out of the bank account can be done as a debit-pullor a credit-push. A debit-pull in the case above is when the company oruser attempts to pull a debit from the bank account. A credit-push iswhen the user authorizes their bank to push funds to a receiver (in thiscase, the company).

4. In many existing systems, payments are completed over ACH orequivalent methods. The initiator is called the originator of therequest. The banking regulations require that the originator be afinancial institution and is typically called the ODFI (OriginatingDepository Financial Institution) and the receiver is called the RDFI(Requesting Depository Financial Institution).

A. In the case of a debit-pull, the ODFI is requesting a debit from theother institution.

B. In the case of a credit-push, the ODFI pushes money to the RDFI.

5. In most cases (but not always), the risk is higher on the ODFI as itis the originator of the request.

Problems with rejections in payments

The steps needed to validate a bank account as a funding source arediscussed above, as well as the attempt to do a debit-pull. During theattempt to pull funds, there can be failures which can lead to a directeconomic loss for the companies. The following is an illustrativeexample using an example company brokerage firm ABC-Trading Inc.

1. A customer of ABC Trading adds a bank account as a funding source fortheir trades and allows ABC Trading to pull and push funds based ontheir trading activity with the brokerage firm.

2. The customer instructs ABC Trading to buy $5,000 worth of a stock anddoes not have sufficient balance in their brokerage account to cover thepurchase.

3. ABC Trading makes the stock purchase and then must initiate a “pull”of $5,000 from the customer's bank account.

4. ABC Trading initiates a debit-pull by issuing ACH debit instructionsto its ODFI. In some cases, ABC Trading may be a bank and can be theODFI. In other cases, the firm may choose one or more banks where it hasa banking relationship to originate the ACH request for them. This canhappen on T+0 or T+1 days depending on the cut off time for the ODFI.

5. The ACH debit instructions can be rejected anywhere from T+0 to T+4days.

6. If at any point, the ACH transfer is rejected, ABC Trading will needto undo the transaction and may be subject to losses if the stock haslost value. There are also operational costs associated with trackingdown the funds from the customer.

The steps above may be repeated many thousands of times per daydepending on the size of the broker. The process is similar for othercompanies that offer services such as bill payments, mortgage payments,or online peer-to-peer payment. The firm takes the risk of anunsuccessful debit from point T+0 to T+4 days when the request iscomplete. The rejections, despite the successful validation of theaccount, are due to the following:

A. Inability to validate the account at point T+0: It is possible thatthe account may have been closed by the user. ABC Trading has noinformation about the closure of the account at point T+0. Following theclosure of the account, any attempt to debit the amounts from theaccount will result in a rejection.

B. Insufficient balance in the account: The account did not havesufficient balance to complete the request. In the example above, theaccount did not have $5000.

C. Other errors: There are several reject codes that NACHA supports.

On demand payments

The systems and methods discussed herein include a hardware and/orsoftware platform that facilitates the movement of assets betweenprincipals. In some embodiments, the participants are large financialinstitutions in capital markets that trade multiple financial products.Trades in capital markets can be complex and involve large assetmovements (also referred to as “settlements”). The clearing andsettlement gateway discussed herein can integrate to financialinstitutions and central settlement authorities such as the U.S. FederalReserve, DTC, and the like to facilitate the final settlement of assets.

In some embodiments, the systems and methods described herein have thefollowing core components:

1. Clearing and Settlement Gateway: This is used to integrate to thecore ledgers of the banks and settlement agencies to initiate andexecute clearing and settlement.

2. Permissioned Shared Ledger: When an asset is cleared or settled, itgoes through several “state changes.” The permissioned shared ledgerrecords the state changes and makes it available to the permissionedparties in substantially real time.

3. Workflows: Parties in a trade can execute complex settlementinstructions that determine the sequence of steps that must be followedto effect the movement of assets between participants. The describedsystems and methods facilitate this with various workflows. In someembodiments, execution of a workflow will result in multipleinstructions that are sent and received through the clearing andsettlement gateway and multiple records in the permissioned sharedledger.

The payments platform discussed herein provides a practical solution tosolve the problems mentioned above.

In some embodiments, the number of funding sources and the amounts ofmonies moved from these funding sources follows an 80-20 rule. That is,80% of the money movement happens from 10 or fewer banks. A solutionthat addresses 80% of the problem will significantly reduce the risksfor companies.

The systems and methods described herein describe the components andoperation of the data ingestion engine. In particular implementations,the data ingestion engine is able to consume the trades, the eventsassociated with the trade, and the metadata associated with the events.The data ingestion engine is a reliable high throughput pipe withidempotency (e.g., replaying same events should not alter the tradedata). The data ingestion engine also supports the ability to ingestdata in different formats from different participants. The systems andmethods can start with an XML format. It is important that the systemsand methods have the ability to normalize the message formats as eachprincipal's data format is likely to be different. Additionally, thedata ingestion engine has the ability to execute downstream modules suchas matching, real time counts, netting, liquidity projections, liquidityoptimizers, anomaly detection, and the like.

In some embodiments, trades have the following characteristics:

1. All parties of the trade (principles, broker-dealers, exchanges,etc.) need to get access the information in near real time.

2. A trade has a life cycle from the point of entry into the system, theexecution, the augmentation of the data in the middle and back officesall the way through to the point where the trade is cleared/settled.Sometimes, the trades may be reversed before it is settled. During thislifecycle, trade metadata is being augmented.

3. The parties of the trade as well as the banks that act as thecustodians of the assets of the principals follow a protocol ofconfirmations and affirmations that are similar to an ACK set in a TCPprotocol (with the noted difference that these are asynchronoussystems).

4. Trades are of different types and the metadata of the trade canchange depending on the type of trade. Metadata can be thought of ascolumns to a row in a csv or fields of attributes in XML or JSON. TheFinancial Information eXchange (FIX) protocol (and the xml version ofit—Fixml) have become standards for the messages to capture the trademetadata between parties.

5. The following can be thought of as a pseudo set theory representationof the problem. There are multiple stages to the problem.

a. Data Ingestion

i. A Node N(i) can trade with parties M(1) . . . M(N) for variousproducts P(1) . . . P(N)

ii. A Trade notation T{(Mi, Ni), Pi} can be used to say that parties Miand Ni have traded a product Pi.

iii. Partial Trade: It is possible that a trade submitted by Ni to Mimay be executed by Mi in separate batches that aggregate to the wholetrade. The examples below show the case of the partial trade and howmatching will work in that case.

iv. A trade will result in several events to be recorded by each partyof the trade. Each event is associated with a set of attributes. Byassociation, these attributes are associated with the trade. Althoughthese attributes are for the trade T{(Mi, Ni), Pi}, Mi and Ni may nothave all the attributes as some attributes may be internal trackingattributes for either Mi or Ni.

v. The data ingestion engine will need to ingest these events and theassociated metadata for an event from both Mi and Ni.

b. Matching

i. The systems and methods will identify these attributes by a(1), a(2). . . a(n). Similar to databases, some of these attributes (or columns)may be primary keys or candidate keys to uniquely identify a trade.Examples of these are counter-party-id, cusip, trade-id, etc.

ii. The systems and methods refer to the E(Tx Mi)=>{a1, a2 . . . an} asthe events for trade ‘Tx’ ingested from Mi. Likewise, the systems andmethods will also refer to E(Tx, Ni)

iii. A trade is said to be ‘Matched to Trade x’ when all the candidatekeys from E(Tx Mi) match those from E(Tx, Ni).

iv. The inverse constitutes to an unmatched trade. That occurs when allthe candidate keys of E(Tx, Mi) do not match E(Tx Ni).

c. Settlement Cycles

i. Settling is the act of closing out the obligations between principalsof a trade. The settlement is the act that involves the movement ofassets. The parties of the trade agree on a point in time in the futureto settle the trades. The systems and methods refer to that as the‘settlement date’.

ii. Note: Not all trades will be settled. Some types of trades are neversettled and just roll forward.

iii. Principals may decide to run multiple settlement cycles on asettlement date.

iv. The systems and methods discussed herein support settlement cycles.

d. Netting

i. Trades may need to be settled in net or in gross. One or more of theattributes of the trades E(Tx Mi)=>{a1, a2 . . . an}, will indicate thesettlement mode (gross vs net). In addition, the attributes will alsoinclude other important fields such as ‘value date’, ‘value amount’,‘settlement date’, ‘settlement cycle’, and the like.

ii. The act of netting will be the following:

1. Group all the matched trades between parties based on the followingjoin criteria (with an AND clause):

a. Matching counterparty: Mi, Ni

b. Same Settlement Date

c. Same Settlement Cycle

d. Settlement type=‘Netted’

2. Compute the sum of the ‘value amounts for each of the groups. This isthe netted amount.

FIG. 7 illustrates an embodiment of an architecture 700 for performingdata ingestion as discussed herein. In some embodiments, each node inarchitecture 700 has trade data in different formats and in differentlocations. Some nodes may have the data available in, for example, anFTP folder. The files may be generated either in real time or by a batchprocess. Other nodes in architecture 700 may have the data available ona file storage system, such as a permissioned storage system or on HDFS(Hadoop Distributed File System). Some nodes in architecture 700 maychoose to make this data available in a queueing system such as anMQseries implementation.

The data resides within the boundaries of the node's systems and datacenters. For the systems and methods to ingest the data, the client willneed an ability to push this data in near time to the financialmanagement system. In some embodiments, a financial management systemtoolkit provides tools and sample code to collect this data and publishit to various systems and components. For example, a “client pushmodule” may establish a secure connection with the financial managementsystem, using one or more client authentication modules to push the datato the financial management system in near real time. A client modulecan do this to handle vast amounts of data on the client side. In someembodiments, there is no attempt to do any normalization of the messagesat the edge. Instead the raw data is pushed to the financial managementsystem in the received format. This is important because anynormalization could alter the data's original format in a manner thatcannot be recovered once published to the financial management system.Additionally, software errors in the client module could mean that thedata might be lost forever.

In some embodiments, node-specific channels are opened (i.e., opening aseparate channel for each node) for several reasons.

-   -   The volume and rate of data will be different for each node. The        system will need the ability to scale up a channel independent        of the other channels. Additionally, a single node should not be        able to overwhelm the system and bring down the ability or add        latency to ingest data from other nodes.    -   Strict SLAs (Service-Level Agreements) may be in place where        commingling of data may not be allowed or encouraged. In some        embodiments, this is treated as a ‘leased line’ to the client.    -   The systems and methods are likely to have backup policies in        place where data may be archived for longer periods of time than        the clients typically keep in their data systems. The backup        should be in the raw formats of the client and not the        normalized format.    -   The systems and methods may change these channels in future.

The data is still in raw and custom format as in the client's site. Thenode-specific channels will feed into a node-specific normalizer whichwill then proceed to normalize the data into a standard format (e.g., astandard format used by financial management system 102). The normalizeddata channel will further feed into the family of optimizers, matchers,and netters.

A node-specific normalizer ingests the custom data from a node, and mapit to a normalized format. This is similar to message-level ETL. Thenode-specific normalizer will ‘load’ the data into the normalized datachannel. The same design patterns that are used for building the customSwift adapters in a clearing gateway may be used in this component aswell.

Functionally, this is a complex layer with the following designconsiderations.

It is difficult to predict the various formats in which the platformwill receive trade messages. Some banks will use the FIX format, butmany others will send these trades in internal/proprietary formats.Sometimes, these could be in binary formats as well as ebcdic. Eachasset class will have its own format. The FIX specification can definedifferent asset classes differently. For cash transfer requests themessages could come in the SWIFT format as well.

When parsing the messages, the parser will need to:

1. Create a set of name value pairs for the data contained in themessage.

2. The data will usually be nested. In creating the name value pairs,the nesting needs to be preserved.

3. Once the nested name value pairs are created, the platform willattempt to normalize the message into a standard format. In someembodiments, the systems and methods can simulate SWIFT messages andnormalize them based on the current standards.

4. Any exceptions during the parsing process are captured. In someembodiments, there is an exception queue where error messages are sent.A dashboard provides access to these messages (exceptions). Theexceptions that are referred to here are typically business exceptions.The systems and methods also handle infrastructure exceptions.

In some embodiments, the described systems and methods do not truncateor make any data unavailable in the normalized form. While thenormalized form may not use all the fields/attributes of the data, anydata not extracted out is still made available.

A normalized data channel is shown as a single logical unit in FIG. 7.This may be further broken down into specific channels for each node.The purpose of normalization is that to enable the systems and methodsto build modules such as netting, matchers, optimizers, ML models, andthe like on a normalized data format.

In some embodiments, each of the channels (e.g., the raw events channelsand the normalized data channels) may have different archival policies.An archival policy will determine the type of persistent (e.g., disk,storage area network, HDFS, etc.), archival, and purging of older data.The policies may be different for a node (and by association, the nodechannel). So, it is important to support the archival policies through aconfiguration.

Some embodiments include matchers and optimizers that are real-timestreaming processors. The following illustrates an example of a matcher.In some embodiments, a particular trade is split into multiple smaller“trade-lets”.

For example, an order to buy 10,000 shares of IBM is placed with a sellside dealer. The dealer then proceeds to ‘execute’ the order. Often, theorder is executed in smaller sizes or lots. The executions are receivedby the back office settlement systems. In this example, assume that theorder of 10,000 shares was executed in lot sizes of 2500 shares each.When it's time to settle the trade, the settlement will occur for all ofthe 10,000 shares (or 4 executions) at the same time. To ensure that thetrade settles completely, the systems and methods stitch together all ofthe unique executions. Once stitched together, the systems and methodscan deem that the trade is ready for settlement.

In some embodiments, the data that is received by the data ingestionengine is for the executions and not the order. The executions will havean associated order ID, which helps the systems and methods stitch theexecutions together.

The retrieval component is important. For example, assume that the firstexecution occurred at 10:00 AM and the second execution occurred at11:00 AM. The chances that the first execution is in memory when thesecond execution is received are low. As a result, the retrievalcomponent will need to determine that: (1) the order is not completewhen the first execution is received and it should be prepared toreceive another execution; (2) when the second execution is received, itneeds to pull out the first execution from the database and “stitch” thetwo executions together; (3) at this time, it also needs to know whetherit should expect a third execution; and (4) note that the third or thefourth execution may or may not occur. This is termed as a partiallyexecuted trade. In some embodiments, the system does not leave thetransaction hanging at the close of the trading day. Instead, thesystems and methods complete it and mark it partial.

The following XML-like snippet can be used. This example is for purposesof illustration and is not representative of a real trade. The realtrade messages are typically proprietary to the client.

Order <Tx>   <OrderID>23847387DHHHD22</OrderID>  <ExecID>667667GttyNm</ExecID>   <Symbol>AAPL</Symbol>  <OrderQty>10000</OrderQty>   <OrderPrice>50</OrderPrice>  <Filled>0</Filled>   <ToBeFilled>10000</ToBeFilled>  <FillPrice>0</FillPrice>  <TransactionTime>20170323-10:00:00:000</TransactionTime> </Tx>

Execution 1 <Tx>   <OrderID>23847387DHHHD22</OrderID>  <ExecID>667667GttyNm</ExecID>   <Symbol>AAPL</Symbol>  <OrderQty>10000</OrderQty>   <OrderPrice>50</OrderPrice>  <Filled>2500</Filled>   <ToBeFilled>7500</ToBeFilled>  <FillPrice>51</FillPrice>  <TransactionTime>20170323-12:00:00:000</TransactionTime> </Tx>

Execution 2 <Tx>   <OrderID>23847387DHHHD22</OrderID>  <ExecID>667667GttyNm</ExecID>   <Symbol>AAPL</Symbol>  <OrderQty>10000</OrderQty>   <OrderPrice>50</OrderPrice>  <Filled>2500</Filled>   <ToBeFilled>5000</ToBeFilled>  <FillPrice>49</FillPrice>  <TransactionTime>20170323-14:00:00:000</TransactionTime> </Tx>

Execution 3 <Tx>   <OrderID>23847387DHHHD22</OrderID>  <ExecID>667667GttyNm</ExecID>   <Symbol>AAPL</Symbol>  <OrderQty>10000</OrderQty>   <OrderPrice>50</OrderPrice>  <Filled>2500</Filled>   <ToBeFilled>2500</ToBeFilled>  <FillPrice>49</FillPrice>  <TransactionTime>20170323-14:00:00:000</TransactionTime> </Tx>

Execution 4 <Tx>   <OrderID>23847387DHHHD22</OrderID>  <ExecID>667667GttyNm</ExecID>   <Symbol>AAPL</Symbol>  <OrderQty>10000</OrderQty>   <OrderPrice>50</OrderPrice>  <Filled>2500</Filled>   <ToBeFilled>2500</ToBeFilled>  <FillPrice>49</FillPrice>  <TransactionTime>20170323-16:00:00:000</TransactionTime> </Tx>

The architecture of FIG. 7 consumes trade data in real-time along withassociated events and related metadata. The architecture is a highthroughput pipe which provides an ability to ingest trade data inmultiple formats. The trade data are normalized to a canonical format,which is used by downstream engines like matching, netting, real-timecounts, liquidity projections, optimizers, and the like. Thearchitecture also provides access to information in real-time todifferent parties of the trade, including calculations such asobligations and exposures of the participating nodes. In someembodiments, the following sub-systems are included in the architecture:

-   -   Trade data generator: generates sample trade data        (order/executions) and pushes to stream.    -   Normalizer: ingests the raw trade data and creates a normalized        (standard format) stream of trade samples.    -   Rudimentary matcher: matches the order with its executions.    -   Obligations/exposures processor: populates the obligations and        exposures for nodes for each asset type and settlement cycles.

FIG. 8 illustrates an embodiment of a process 800 for performing dataingestion as discussed herein. In some embodiments, a trade datagenerator generates sample trade data, required for all the downstreamprocesses. The generated trade data is in various formats such as CSV,XML, or JSON. The generated trade data contains, for example, thefollowing fields: order_id, execution_id, primary_node_id,secondary_node_id, settlement_date, settlement_cycle, symbol,order_price, fill_price, order_quantity, filled_quantity,to_be_filled_quantity.

symbol: symbol of the security that is to be bought or sold

fill_price: +/−10% of the order_price. For some trades, the fill priceneeds to be the same as the order price.

order_quantity=filled_quantity+to_be_filled_quantity.

The generated trade data will have both orders and executions. An ordercan have multiple executions. For example, an order to buy 500 shares ofIBM can have 5 executions, with each individual execution having anorder quantity of 100 IBM shares. An order or execution isdifferentiated by the availability of the execution id.

Orders/executions are generated for all trading hours. For example, ifthe data generator is triggered on May 23, 2017 with an argument togenerate 100 orders, the data generator generates 100 orders (along withexecutions). Both the buy and sell side of the trade have events thatare added to the data ingestion pipeline. There is one stream for eachprimary node. So, for each trade, there will be two events (one for buyand one for the sell side of the trade). Thus, for each order execution,there will be two streams—one for the buyer and one for the seller.

For example, suppose there are three participant nodes that are involvedin bilateral trade between themselves. The data will be generated inthree separate streams: node_a, node_b, and node_c, (corresponding tonodes 1, 2 and 3). The data in the stream node_a will be the recordswhere node1 is the primary_node_id and so on.

The generated order will be of various types, such as completed orders,pending orders, and exceptions.

Completed orders—The data generator generates orders for every hour forthe date on which the job is run. While generating orders for everyhour, the generator randomly completes an order in the subsequent hours.

Pending orders—Some orders will not complete at all.

Exceptions—Some orders will have more executions than expected. Forexample, an order of 500 shares of IBM may have six executions, witheach individual execution having an order quantity of 100 IBM shares.This is an exception because the sum of the order quantity in theindividual executions exceeds the order quantity specified in the order.

After generating the trade samples, the data generator creates twosummary files. One summary file provides the details of the number oforders that has been generated for every hour grouped by order types.Another summary file has the cumulative count of the various types oforders at the end of every hour. For example, if the generator hasgenerated 10 pending and 12 completed orders in 00 hour and 5 pendingand 10 completed orders in 01 hour, the summary file will have a countof 15 pending and 22 completed orders for the 01 hour. The generatoralso provides the total number of records (both orders and executions)that have been generated in that particular run. If the size of the filein which the trade data is being generated exceeds the maximum limit,file rotation is performed. For example, the system can have multiplefiles for a single hour such as 00.csv, 00.csv.1, . . . and so on.

The normalizer reads the streaming trade data from the stream andconverts that into a standard format which is a simplified version ofthe FIXML standard. The normalized messages are then pushed to a newstream which will be consumed by downstream systems.

In a particular example, the incoming message (orders) to the normalizerare given below:

babacf6a-0c20-44b9-b837-5d1a28fc0acb,ABT,1500,100,0,1500,0,05/04/201701:55

The corresponding Normalized format is

<Order>  <ClOrdID>babacf6a-0c20-44b9-b837-5d1a28fc0acb</ClOrdID> <ClExeID></ClExeID>  <Side></Side>  <OrdTyp></OrdTyp>  <Px>100</Px> <Acct></Acct>  <PriNode></PriNode>  <SecNode></SecNode>  <Instrmt>  <Sym>ABT</Sym>   <ID></ID>   <IDSrc></IDSrc>  </Instrmt>  <OrdQty>  <Qty>1500</Qty>  </OrdQty>  <meta_data></meta_data> <TransactTime>05/04/2017 01:55</TransactTime> </Order>

The matcher is a windowed stream processing component. In someembodiments, the matcher reads from the normalized stream (trade data inFIXML format) and computes the status of the orders. FIG. 9 illustratesan embodiment of a schema 900 produced as a stream by the matcher.

In a matcher algorithm, a message received by the matcher may be anorder or an execution. If the received message is an order, the orderwill get inserted into the database (as described in the schema shown inFIG. 9). The status of the order is marked as pending. When an executionarrives at the matcher, the matcher will check if the order for theincoming execution has already arrived or not. If the order isavailable, the “no_of_executions”, “order_quantity_received”, and“execution_metadata” columns are updated accordingly. For everyexecution received, the matcher compares the order quantity with the sumof the order quantities in the executions that have been received sofar.

If the order quantity received so far is less than the original orderquantity (quantity available in the order), the status of the order isPENDING.

If the order quantity received so far is equal to the original orderquantity (quantity available in the order), the status of the order isCOMPLETED.

If the order quantity received so far is greater than the original orderquantity (quantity available in the order), the status of the order isEXCEPTION.

For example, suppose an order is to buy 100 IBM shares at 50 USD for agiven particular settlement cycle (all other parameters will also beavailable). The order can be split into four executions each of 25 IBMshares. When the first execution arrives with an order quantity 25, thematcher will update the “no_of_executions” column to 1,“order_quantity_received” column to 25 and the status as PENDING sincethe order quantity and the received order quantity does not match.During the second execution (order quantity 25) the “no_of_executions”column is updated to 2 “order_quantity_received” column to 25 and thestatus to PENDING. Likewise, for the third execution. During the fourthexecution the status will be updated to COMPLETED.

If any new executions arrive (order quantity 50) for the same order, thestatus of the order becomes EXCEPTION, since the“order_quantity_received” is greater than the actual order quantitypresent in the order.

All the COMPLETED orders will be pushed to a new kinesis stream at theinstant when the status changes from pending to completed. The matcherdoes this while updating the status column for every execution.

The obligations/exposures processor is a stream processing componentthat receives all the COMPLETED orders from the new stream (output ofrudimentary matcher) and computes the obligations and exposures in realtime. The obligations/exposures processor aggregates the sum of orderquantities and the corresponding price to arrive at the obligations andexposures of a particular node, for a given asset type. FIG. 10illustrates an embodiment of a logical sample 1000 of obligations andexposures.

Settlement is performed on a netted basis. After netting is finished,the DVP instruction for that settlement is pushed to a queue that isconsumed by the workflow engine. Netting can be of five types. Even ifnetting is done, all individual orders that form the netting will becaptured as metadata. There are different types of netting, which arediscussed below.

Type 1—Simple netting. Netting is done only for identical primary andsecondary nodes with the same settlement date, settlement cycle, andasset type. FIG. 11 illustrates an embodiment of three orders 1100received by an obligations/exposures processor. In this example, two DVPinstructions are sent to the queue: one for settling the exchangebetween nodes A and B for the cumulative sum of 30 IBM shares inexchange of 200 USD, and another instruction to exchange from Node B toNode A for 30 IBM shares in exchange of 100 EUR.

A second type of netting is settling only for the remaining amount orsecurities after cancelling the exposures of that node. FIG. 12illustrates an embodiment of the second type of netting with four sampleorders 1200. In the example of FIG. 12, node A has obligations to node Band node B has obligations to node A. So, a single DVP instruction issent for the exchange between node B to node A for 5 IBM shares inexchange of 50 USD (the obligations from both ends are cancelled).

A third type of netting is cancelling the identical currency exchangefrom both sides. FIG. 13 illustrates an embodiment of the third type ofnetting with two sample orders 1300. In the example of FIG. 13, thesettlement instruction will be sent only for exchanging 100 IBM sharesin exchange on 200 APPL shares. The other settlement instruction forexchanging 1000 USD for 1000 USD will be cancelled out.

A fourth type of netting is cancelling the identical securities fromboth sides. FIG. 14 illustrates an embodiment of this fourth type ofnetting with two sample orders 1400. In the example of FIG. 14, thesettlement instruction will be sent only for exchanging currency betweennode A and B for 100 USD in exchange of 99 EUR. The other settlementinstruction to exchange 100 IBM shares for 100 IBM shares will becancelled.

A fifth type of netting is settling as more than one instruction. FIG.15 illustrates an embodiment of this fifth type of netting with twosample orders 1500. In the example of FIG. 15, two settlementinstructions will be created between node A and B for 1000 USD inexchange of 1000 EUR. The exchange of two IBM shares will be cancelledout.

Once a settlement is completed, there is a feedback loop into the inputstream of the obligations and exposures processor that will adjust theobligations and exposures.

A particular example is discussed below with respect to a regulatorynode. For the regulatory node functionality, the following sub-systemsare used: Data Generation, Normalizer, Matching, Obligations andexposures, Generation of settlement instructions with Netting, Feedbackfrom settlement system to update the obligations and exposures, and UIreports.

Data Generation: In this example, the trades are assumed to be bilateraland hence each node has the information on who it is selling to orbuying from. The data generation is currently computed at order idlevel. This has the following fields.

1. Primary node

2. Secondary node

3. Order id

4. Symbol

5. Order quantity

6. Order price

7. Execution id

8. Record type

9. Order date

10. Settlement date

For the purposes of this example, three nodes are described—node1,node2, and node3. For each order there will be a corresponding buy andsell record. The data will be generated in 3 separate streams—node_a,node_b, node_c, (corresponding to nodes 1, 2 and 3). The data in thestream node_a will be the records where node1 is the primary_node_id andso on. The kinesis client will push the CSV records to 3 separatestreams (node-a-sample, node-b-sample, node-c-sample).

Normalizer—In an actual situation, the normalizer would convert eachnodes' separate data to the fixed format. For the purposes of thisexample, the system converts all the csv data from each of the separatestreams to json and writes to one stream—normalized-sample.

Matching—The matching system looks into the buy and sell records andmatches on the order id and produces buyer, seller, and tradeinformation with settlementDate in a separate stream calledsettlement-sample.

Obligations and exposures—The obligations and exposures are computed onthe matched ordered stream (i.e., the settlement-sample) and it producesyet another stream—obligations-exposures.

Example of netting and settlement instructions—When the system sends asignal to the obligations and exposures processor, it sends one recordwhen the settlement happens. FIG. 16 illustrates an embodiment of asignal 1600 that is sent when the settlement happens for a netted entry.In the example of FIG. 16, the signal that is sent on thesettlement-sample stream (i.e., the input to the obligations-processor)includes:

N1,N2,A,6/15/2017 11:00,−2900,−165 (i.e., −1*the value)

FIG. 17 illustrates an embodiment of another signal 1700 that is sentwhen the settlement happens for a netted entry. In the example of FIG.17, the signal that is sent on the settlement-sample stream (i.e., theinput to the obligations-processor) includes:

N1,N2,A,6/15/2017 11:00,250,−25

In some embodiments, the described systems and methods include a fieldcalled recordType in matched_orders. The stream application enters‘MATCHED-ORDERS’ into the recordType. The feedback signal can enter‘SETTLEMENT’ so the systems and methods can ignore the feedback signalswhere needed.

FIG. 18 illustrates an embodiment of a data flow diagram 1800 as asample application. The simulated data flow has the following steps:

-   -   Data generator to create trades for the 3 nodes involved        (node−a, node=b, node-c)    -   Node specific stream application consumes the trades    -   Each stream normalizes the data    -   Realtime Order matching is performed on normalized data    -   Matched Order stream is used to generate real-time obligation        and exposures    -   Obligations/Exposures are stored in a database to provide        reporting APIs    -   Matched orders are also stored in another database to be used in        other downstream processing like settlement

Settlement Service—The settlement service and reporting layer are thefinal stages of the data ingestion pipeline. Both of these services willobtain the required data from the analytics applications. The data fromthe analytics applications will be pushed to data warehouses, which areused to store historical view of obligations and exposures. Thesettlement service is responsible for calculating the netted values ofthe trades that has been ingested and for scheduling the trades tosettle on the requested settlement cycle.

Workflow Monitoring Service—The workflow monitor service will monitorthe workflow queue to listen for events propagated by the workflowengine. These events hold the status of the workflow. If the status ofthe workflow changes, this service will update the newer status into thesettlements table. Once the workflow status becomes COMPLETE, a feedbacksignal is sent to the matched orders stream with record type as“Feedback”.

Feedback signal—The feedback signal is similar to the csv data of thematched orders as shown below, which refers the buyer, seller, symbol,settlement cycle, total value, and quantity. The example signalincludes: N1,N2,A,6/15/2017 11:00,−2900,−165

The values of total value and quantity will be negative, which indicatesthe settlement has already been completed. The two fields hold theaggregated values of the order value and order quantity of theindividual orders that contribute the netting.

As discussed herein, the described systems and methods are particularlyuseful in handling large amounts of data associated with capitalmarkets. For example, these systems and methods can handle the datathroughput and latency associated with a large volume of financialtransactions in various types of capital markets. These markets canprocess one billion or more events on a daily basis. Events include, forexample, placing an order, updating an order, fulfilling an order,partially filling an order, initiating an order to sell, initiating anorder to buy, amending an existing order, executing a transaction, andthe like. Any number of trading systems in a capital market match buyorders or sell orders with one or more corresponding sell orders or buyorders. For example, an order to sell 1000 shares of a particular stockmay be executed as multiple corresponding buy orders totaling 1000shares initiated by one or more trading systems. Thus, the initial orderto sell 1000 shares may cause multiple buy orders, resulting in multipleevents for the single order to sell. The systems and methods describedherein can handle these types of events in high volume with acceptablelatency and in substantially real time.

Additionally, the described systems and methods are useful in analyzingthe various financial data associated with the high volume of events. Inparticular, the described systems and methods can handle streaminganalytics for one or more financial markets (including all events)across multiple financial institutions in substantially real time.

When an order is placed with a financial institution, a liquidity demandwill be placed on the financial institution at some time in the future.The liquidity demand may indicate that the financial institution is toreceive funds in the future or the financial institution must pay fundsin the future. The funds can be in different asset types, such ascurrency, securities, bills, bonds, and the like. Additionally, thefunds can be in different financial jurisdictions. Each liquidity demandis with a counterparty (or multiple counterparties). So, a particularfinancial institution with multiple liquidity demands is typicallydealing with multiple different counterparties, where each counterpartyhas different a different risk profile. Some counterparties may be moreprone to risk than other counterparties, and the risk profile of eachcounterparty may change regularly based on changing liquidity demands,changing exposures, changing obligations, credit profile, and otherfactors. The risk profile of a counterparty is also based on ajurisdiction, where some jurisdictions have a higher risk for fraud orfailed payment than other jurisdictions. For example, the risk profilefor a particular financial institution changes in substantially realtime based on what funds are owed to the financial institution and theamount of funds owed to other financial institutions.

In addition to the risk profile, a liquidity profile for a particularfinancial institution is defined based on how much is owed to thefinancial institution and how much the financial institution owes toothers (e.g., exposures and obligations).

In previous systems, financial institutions do not have access toliquidity demands, risk profiles, or liquidity profiles for otherfinancial institutions in substantially real time. These existingsystems are limited to a particular financial institution's data and donot provide visibility into the risk profile or liquidity profile ofother financial institutions.

However, the systems and methods described herein do providesubstantially real time data associated with liquidity demandinformation for a particular financial institution by jurisdiction, byasset type, and by counterparty. These systems and methods operate in adistributed environment that includes multiple financial institutions,multiple data formats, and the like.

Additionally, the described systems and methods provide substantiallyreal time data associated with a financial institution's risk profilebased on the counterparties, jurisdictions, time zones, and the like.Thus, these systems and methods allow a particular financial institutionto determine its current liquidity profile and risk profile insubstantially real time, which was not previously available. This isaccomplished by processing streams of financial data in substantiallyreal time as it flows through the financial market. Additionally, thedata from different financial institutions and different data feeds isnormalized for consistent processing.

An example liquidity demand has multiple components (or dimensions):

1. Each counterparty

2. Each asset type being exchanged with a counterparty

3. Other factors

These multiple components (or dimensions) are evaluated each time theliquidity demand is calculated or updated.

In some embodiments, different financial institutions in a distributedenvironment may have different business rules. For example, a particularbusiness rule for a specific financial institution may state that if arisk exposure exceeds a predetermined threshold value (based oncurrency, jurisdiction, etc.), the financial institution needs to takeaction to mitigate its risk, such as generate an alert, force asettlement, open another position with a different counterparty toreduce exposure, and the like. In particular implementations, thepredetermined threshold value includes a predetermined risk thresholdand/or a predetermined liquidity threshold.

In some embodiments, the described systems and methods apply variousstatistical models to data communicated through the distributed systemsand capital markets discussed herein. For example, the data isnormalized by the systems and methods, then the normalized data isapplied to a statistical model. The statistical model may represent arisk model associated with a particular financial institution. In someimplementations, each financial institution may create its ownstatistical models and/or risk models based on that financialinstitution's risk tolerances and risk preferences. For example,different financial institutions may use different factors (and applydifferent weightings to various factors) when determining their own risktolerance. These factors include, for example, past history with acounterparty, current exposures, current obligations, and the like.Thus, each financial institution's statistical model may generate itsown unique risk score.

Additionally, the systems and methods described herein may applymultiple different statistical models to the same data to achievemultiple risk scores. These multiple risk scores are useful to financialinstitutions for different types of trades or products. For example,different risk scores may be used for spots vs. swaps.

In existing systems, financial institutions may have a limited amount ofcounterparty data since the data is spread across multiple internalsystems. But, the systems and methods described herein allow financialinstitutions to obtain a holistic view of data across all currencies,all jurisdictions, all counterparties, all products, etc.

The described systems allow a financial institution to calculate riskexposure and identify high-risk counterparties. The portion of dataavailable as part of a trade is available to the financial institution.But, private data associated with a particular financial institution isnot shared with other institutions. Thus, a financial institution canidentify high-risk counterparties in substantially real time and takeaction, if necessary, to mitigate their risk associated with thehigh-risk counterparties.

FIG. 19 illustrates an embodiment of a method 1900 for managing afinancial institution's risk and liquidity. Initially, a financialmanagement system monitors 1902 all data associated with multiple eventsin a financial market in substantially real time. The financialmanagement system then analyzes 1904 the data associated with multipleevents in a particular financial market in substantially real time.Based on the analysis in 1904, the financial management systemdetermines 1906 a financial institution's liquidity demand, liquidityprofile, and risk profile. Method 1900 continues as the financialmanagement system communicates 1908 the financial institution'sliquidity demand, liquidity profile, and risk profile to one or morefinancial institutions, entities or systems. Finally, the financialinstitution, entity or system can take action 1910 if the financialinstitution's risk exposure exceeds a threshold value.

FIG. 20 illustrates an example state diagram 2000 showing various statesthat a transaction may pass through. As shown in FIG. 20, a particulartransaction may be initiated (“new”), then clearing is initiated with abank, after which the transaction's state is “clearing pending.” Thenext transaction state is “cleared”, then settlement is initiated, afterwhich the transaction state is “settlement pending.” After thetransaction has settled, the state becomes “completed.” As shown instate diagram 2000, the state diagram may branch to “cancelled” atlocations in the state diagram. For example, a transaction may becancelled due to insufficient funds, a mutual decision to reverse thetransaction before settlement, a bank internal ledger failure, and thelike. Additionally, the state diagram may branch to “rolled back” atmultiple locations. For example, a transaction may be rolled back due toan unrecoverable error, a cancellation of the transaction, and the like.

Each transaction and the associated transaction states may haveadditional metadata. The shared ledger (e.g., ledger 118 in FIG. 1) mancontain all the state information and state changes for a transaction. Aseparate record is maintained for each state of the transaction. Therecord is not updated or modified. In some embodiments, all transactionsare final and irreversible. The metadata for the new transactionincludes a reference to the erroneous transaction that needs to bereversed. The parties are informed of the request to reverse theerroneous transaction as part of a new transaction. The new transactionalso goes through the state changes shown in FIG. 20. When the newtransaction is completed, the metadata of the initial transaction isalso updated.

In some embodiments, the transactions and the metadata recorded in theshared permissioned ledger contain information that are very sensitiveand confidential to the businesses initiating the instructions. Thesystems and methods described herein maintain the security of thisinformation by encrypting data for each participant using a symmetrickey that is unique to the participant. In some embodiments, the keysalso have a key rotation policy where the data for that node is rekeyed.The keys for each node are bifurcated and saved in a secure storagelocation with role-based access controls. In some embodiments, only aspecial service called a cryptographic service can access these keys atruntime to encrypt and decrypt the data.

FIG. 21 is a block diagram illustrating an embodiment 2100 of afinancial management system 2102 interacting with a cryptographicservice 2108 and multiple client nodes 2104 and 2106. Although twoclient nodes 2104, 2106 are shown in FIG. 21, alternate embodiments mayinclude any number of client nodes coupled to financial managementsystem 2102. In the embodiment of FIG. 21, financial management system2102 communicates with client nodes 2104, 2106 to manage one or moretransactions between client nodes 2104 and 2106, or between one ofclient nodes 2104, 2106 and other client nodes, devices, or systems (notshown). Financial management system 2102 also communicates withcryptographic service 2108, which manages secure access to a data store2114. In some embodiments, data store 2114 is a shared ledger (e.g.,ledger 118 in FIG. 1) of the type discussed herein. In theseembodiments, data store 2114 represents the capabilities of the sharedledger as they relate to data permissions.

As shown in FIG. 21, data store 2114 stores encrypted data associatedwith client nodes 2104 and 2106. In alternate embodiments, data store2114 may store encrypted data associated with any number of clientnodes. Cryptographic service 2108 ensures security of the data in datastore 2114 using, for example, secure bifurcated keys that are stored innode 1 key storage 2110 and node 2 key storage 2112. Each key is uniquefor the associated client node. When financial management system 2102wants to access data from data store 2114, the data access request mustinclude an appropriate key to ensure that the data access request isauthorized.

Each transaction can have two or more participants. In addition to themultiple parties involved in the transaction, there can be one or more“observers” to the transaction. The observer status is important from acompliance and governance standpoint. For example, the Federal Reserveor the CFTC is not a participant of the transaction, but may haveobserver rights on certain type of transactions in the system. In someembodiments the participants can subscribe to certain types of events.The transaction state in the state diagram above changes trigger eventsin the described systems.

FIG. 22 is a block diagram illustrating an example computing device2200. Computing device 2200 may be used to perform various procedures,such as those discussed herein. Computing device 2200 can function as aserver, a client, a client node, a financial management system, or anyother computing entity. Computing device 2200 can be any of a widevariety of computing devices, such as a workstation, a desktop computer,a notebook computer, a server computer, a handheld computer, a tablet, asmartphone, and the like. In some embodiments, computing device 2200represents any of the computing devices discussed herein.

Computing device 2200 includes one or more processor(s) 2202, one ormore memory device(s) 2204, one or more interface(s) 2206, one or moremass storage device(s) 2208, and one or more Input/Output (I/O)device(s) 2210, all of which are coupled to a bus 2212. Processor(s)2202 include one or more processors or controllers that executeinstructions stored in memory device(s) 2204 and/or mass storagedevice(s) 2208. Processor(s) 2202 may also include various types ofcomputer-readable media, such as cache memory.

Memory device(s) 2204 include various computer-readable media, such asvolatile memory (e.g., random access memory (RAM)) and/or nonvolatilememory (e.g., read-only memory (ROM)). Memory device(s) 2204 may alsoinclude rewritable ROM, such as Flash memory.

Mass storage device(s) 2208 include various computer readable media,such as magnetic tapes, magnetic disks, optical disks, solid statememory (e.g., Flash memory), and so forth. Various drives may also beincluded in mass storage device(s) 2208 to enable reading from and/orwriting to the various computer readable media. Mass storage device(s)2208 include removable media and/or non-removable media.

I/O device(s) 2210 include various devices that allow data and/or otherinformation to be input to or retrieved from computing device 2200.Example I/O device(s) 2210 include cursor control devices, keyboards,keypads, microphones, monitors or other display devices, speakers,printers, network interface cards, modems, lenses, CCDs or other imagecapture devices, and the like.

Interface(s) 2206 include various interfaces that allow computing device2200 to interact with other systems, devices, or computing environments.Example interface(s) 2206 include any number of different networkinterfaces, such as interfaces to local area networks (LANs), wide areanetworks (WANs), wireless networks, and the Internet.

Bus 2212 allows processor(s) 2202, memory device(s) 2204, interface(s)2206, mass storage device(s) 2208, and I/O device(s) 2210 to communicatewith one another, as well as other devices or components coupled to bus2212. Bus 2212 represents one or more of several types of busstructures, such as a system bus, PCI bus, IEEE 1394 bus, USB bus, andso forth.

For purposes of illustration, programs and other executable programcomponents are shown herein as discrete blocks, although it isunderstood that such programs and components may reside at various timesin different storage components of computing device 2200, and areexecuted by processor(s) 2202. Alternatively, the systems and proceduresdescribed herein can be implemented in hardware, or a combination ofhardware, software, and/or firmware. For example, one or moreapplication specific integrated circuits (ASICs) can be programmed tocarry out one or more of the systems and procedures described herein.

In the above disclosure, reference has been made to the accompanyingdrawings, which form a part hereof, and in which is shown by way ofillustration specific implementations in which the disclosure may bepracticed. It is understood that other implementations may be utilized,and structural changes may be made without departing from the scope ofthe present disclosure. References in the specification to “oneembodiment,” “an embodiment,” “an example embodiment,” “selectedembodiments,” “certain embodiments,” etc., indicate that the embodimentor embodiments described may include a particular feature, structure, orcharacteristic, but every embodiment may not necessarily include theparticular feature, structure, or characteristic. Additionally, suchphrases are not necessarily referring to the same embodiment. Further,when a particular feature, structure, or characteristic is described inconnection with an embodiment, it is submitted that it is within theknowledge of one skilled in the art to affect such feature, structure,or characteristic in connection with other embodiments whether or notexplicitly described.

Implementations of the systems, devices, and methods disclosed hereinmay comprise or utilize a special purpose or general-purpose computerincluding computer hardware, such as, for example, one or moreprocessors and system memory, as discussed herein. Implementationswithin the scope of the present disclosure may also include physical andother computer-readable media for carrying or storingcomputer-executable instructions and/or data structures. Suchcomputer-readable media can be any available media that may be accessedby a general purpose or special purpose computer system.Computer-readable media that store computer-executable instructions arecomputer storage media (devices). Computer-readable media that carrycomputer-executable instructions are transmission media. Thus, by way ofexample, and not limitation, implementations of the disclosure caninclude at least two distinctly different kinds of computer-readablemedia: computer storage media (devices) and transmission media.

Computer storage media (devices) includes RAM, ROM, EEPROM, CD-ROM,solid state drives (“SSDs”) (e.g., based on RAM), Flash memory,phase-change memory (“PCM”), other types of memory, other optical diskstorage, magnetic disk storage or other magnetic storage devices, or anyother medium which can be used to store desired program code means inthe form of computer-executable instructions or data structures andwhich can be accessed by a general purpose or special purpose computer.

An implementation of the devices, systems, and methods disclosed hereinmay communicate over a computer network. A “network” is defined as oneor more data links that enable the transport of electronic data betweencomputer systems and/or modules and/or other electronic devices. Wheninformation is transferred or provided over a network or anothercommunications connection (either hardwired, wireless, or a combinationof hardwired and wireless) to a computer, the computer properly viewsthe connection as a transmission medium. Transmissions media can includea network and/or data links, which can be used to carry desired programcode means in the form of computer-executable instructions or datastructures and which can be accessed by a general purpose or specialpurpose computer. Combinations of the above should also be includedwithin the scope of computer-readable media.

Computer-executable instructions include, for example, instructions anddata which, when executed at a processor, cause a general purposecomputer, special purpose computer, or special purpose processing deviceto perform a certain function or group of functions. Thecomputer-executable instructions may be, for example, binaries,intermediate format instructions such as assembly language, or evensource code. Although the subject matter has been described in languagespecific to structural features and/or methodological acts, it is to beunderstood that the subject matter defined in the appended claims is notnecessarily limited to the described features or acts described above.Rather, the described features and acts are disclosed as example formsof implementing the claims.

Those skilled in the art will appreciate that the disclosure may bepracticed in network computing environments with many types of computersystem configurations, including, personal computers, desktop computers,laptop computers, message processors, hand-held devices, multi-processorsystems, microprocessor-based or programmable consumer electronics,network PCs, minicomputers, mainframe computers, mobile telephones,PDAs, tablets, pagers, routers, switches, various storage devices, andthe like. The disclosure may also be practiced in distributed systemenvironments where local and remote computer systems, which are linked(either by hardwired data links, wireless data links, or by acombination of hardwired and wireless data links) through a network,both perform tasks. In a distributed system environment, program modulesmay be located in both local and remote memory storage devices.

Further, where appropriate, functions described herein can be performedin one or more of: hardware, software, firmware, digital components, oranalog components. For example, one or more application specificintegrated circuits (ASICs) can be programmed to carry out one or moreof the systems and procedures described herein. Certain terms are usedthroughout the description and claims to refer to particular systemcomponents. As one skilled in the art will appreciate, components may bereferred to by different names. This document does not intend todistinguish between components that differ in name, but not function.

It should be noted that the sensor embodiments discussed above maycomprise computer hardware, software, firmware, or any combinationthereof to perform at least a portion of their functions. For example, amodule may include computer code configured to be executed in one ormore processors, and may include hardware logic/electrical circuitrycontrolled by the computer code. These example devices are providedherein purposes of illustration, and are not intended to be limiting.Embodiments of the present disclosure may be implemented in furthertypes of devices, as would be known to persons skilled in the relevantart(s).

At least some embodiments of the disclosure have been directed tocomputer program products comprising such logic (e.g., in the form ofsoftware) stored on any computer useable medium. Such software, whenexecuted in one or more data processing devices, causes a device tooperate as described herein.

While various embodiments of the present disclosure are describedherein, it should be understood that they are presented by way ofexample only, and not limitation. It will be apparent to persons skilledin the relevant art that various changes in form and detail can be madetherein without departing from the spirit and scope of the disclosure.Thus, the breadth and scope of the present disclosure should not belimited by any of the described exemplary embodiments, but should bedefined only in accordance with the following claims and theirequivalents. The description herein is presented for the purposes ofillustration and description. It is not intended to be exhaustive or tolimit the disclosure to the precise form disclosed. Many modificationsand variations are possible in light of the disclosed teaching. Further,it should be noted that any or all of the alternate implementationsdiscussed herein may be used in any combination desired to formadditional hybrid implementations of the disclosure.

1. A method comprising: identifying, by a financial management system,data associated with a plurality of events in a financial market insubstantially real time; analyzing, by the financial management system,the data associated with the plurality of events; responsive toanalyzing the data associated with the plurality of events, determininga liquidity demand, a liquidity profile, and a risk profile associatedwith a particular financial institution; and communicating, by thefinancial management system, the financial institution's liquiditydemand, liquidity profile, and risk profile to the financialinstitution.
 2. The method of claim 1, wherein the plurality of eventsare associated with the purchase or sale of securities.
 3. The method ofclaim 1, wherein analyzing the data associated with the plurality ofevents includes comparing a financial institution's risk profile to apredetermined risk threshold.
 4. The method of claim 3, whereincommunicating the financial institution's liquidity demand, liquidityprofile, and risk profile to the financial institution occurs inresponse to the financial institution's risk profile exceeding thepredetermined risk threshold.
 5. The method of claim 1, whereinanalyzing the data associated with the plurality of events includesanalyzing a plurality of liquidity demands associated with a particularfinancial institution, wherein the plurality of liquidity demands arewith different counterparties.
 6. The method of claim 5, whereinanalyzing the data associated with the plurality of events furtherincludes determining a risk profile associated with each of thedifferent counterparties.
 7. The method of claim 6, further comprisingre-analyzing the data associated with the plurality of events over aperiod of time to detect changes in risk profiles associated with thedifferent counterparties.
 8. The method of claim 1, wherein analyzingthe data associated with the plurality of events includes comparing afinancial institution's liquidity profile to a predetermined liquiditythreshold.
 9. The method of claim 1, wherein analyzing the dataassociated with the plurality of events includes analyzingcounterparties, jurisdictions, and time zones.
 10. The method of claim1, wherein analyzing the data associated with the plurality of eventsincludes determining a particular financial institution's rulesregarding acceptable risk exposure.
 11. The method of claim 1, whereinanalyzing the data associated with the plurality of events includesapplying a statistical model to data associated with the plurality ofevents.
 12. The method of claim 1, wherein analyzing the data associatedwith the plurality of events includes applying a plurality ofstatistical models to the data associated with the plurality of eventsto generate a plurality of risk scores.
 13. The method of claim 11,wherein the statistical model represents a risk model associated with aparticular financial institution.
 14. The method of claim 1, whereinanalyzing the data associated with the plurality of events includesanalyzing data across multiple currencies, multiple jurisdictions,multiple counterparties, and multiple products.
 15. A method comprising:identifying, by a financial management system, data associated with aplurality of events in a financial market in substantially real time;analyzing, by the financial management system, the data associated withthe plurality of events, wherein analyzing the data associated with theplurality of events includes: comparing a financial institution'scurrent risk profile to a predetermined risk threshold; comparing afinancial institution's current liquidity profile to a predeterminedliquidity threshold; determining a liquidity demand, a liquidityprofile, and a risk profile associated with a particular financialinstitution based on analyzing the data associated with the plurality ofevents.
 16. The method of claim 15, further comprising communicating, bythe financial management system, the financial institution's liquiditydemand, liquidity profile, and risk profile to the financialinstitution.
 17. The method of claim 15, wherein analyzing the dataassociated with the plurality of events includes applying a statisticalmodel to data associated with the plurality of events.
 18. The method ofclaim 15, wherein analyzing the data associated with the plurality ofevents includes analyzing data across multiple currencies, multiplejurisdictions, multiple counterparties, and multiple products.
 19. Anapparatus comprising: a data ingestion system configured to receive dataassociated with a plurality of events in a financial market insubstantially real time; and a financial management system coupled tothe data ingestion system, wherein the financial management system isconfigured to: analyze the data associated with the plurality of events;determine a liquidity demand, a liquidity profile, and a risk profileassociated with a particular financial institution based on the analysisof the data associated with the plurality of events; and communicate thefinancial institution's liquidity demand, liquidity profile, and riskprofile to the particular financial institution.
 20. The apparatus ofclaim 19, wherein the analysis of the data associated with the pluralityof events includes comparing a financial institution's risk profile to apredetermined risk threshold.